1. Apps and App Stores
Since the advent of
Qualcomm's BREW and Java's J2ME technology in the early 2000s, mobile
users have had the ability to download applications to their mobile
devices. These applications (or "midlets" in the J2ME terminology) were
simple at first, partly because the environments were limited and partly
because the devices themselves did not feature powerful CPUs and
graphic capabilities. Indeed, some of the first J2ME handsets did not
even feature color displays.
As handset technology
developed, however, such client-side technologies started to prove an
effective way to add exciting functionality to devices that were not
otherwise upgradable. The games industry in particular started to use
J2ME and BREW as a way of delivering small games or ports of classic
arcade titles, and devices started to support richer, faster APIs to
allow such applications to do so effectively.
The advantages of even a
client-side application are manifold. For a user, after the application
has been downloaded, there is no limit to how or where it can be used,
and since most applications do not require a network connection, there
is no risk of incurring high data network charges. The applications can
run full screen, store data locally, and access much of the handset's
physical capabilities (such as the camera or audio hardware). For a
network carrier or application provider, the single event of downloading
an application is eminently billable, and beginning around 2005, mobile
carriers' portals worldwide quickly filled with directories of games
and utilities that could be downloaded for a few dollars.
However, such applications
still require the user to have a correctly configured data connection in
order to download them, and such directories remained notoriously
difficult to search and navigate. When Apple launched its App Store in
mid 2008, together with preconfigured support on its iPhone models which
made it particularly easy to download and pay for applications, the
concept of client-side mobile applications started to attract mainstream
attention. Less than two years later, the App Store features 200,000
different applications and has provided 4 billion downloads.
Figure 1
shows Apple's App Store as it appears in iTunes on a user's computer.
Purchased applications are then synchronized with the handset via a USB
cable. More easily, users can browse and purchase applications directly
from their iPhone, iPod, or iPad device, as shown in Figure 2, and download them over a cellular or wireless network.
This volume of traffic on
Apple's App Store and the potential to allow users to pay for
applications via their iTunes account causes lots of interest among
developers, and currently a large and vibrant community of individuals
and start-ups create games and applications for the iPhone. A
significant number can be considered commercial successes, although many
are available for free or do not become profitable given the common
price point of a few U.S. dollars per application. More intriguingly,
however, many larger companies or well-known brands have developed and
published apps into the App Store, and in many cases these are designed
to act much like a corporate website.
Figure 3
shows a screenshot of the BBC News application running on the iPhone
platform, which shows a formatted version of the news feed from its
website. Figure 2-18
shows an application made by fashion house Chanel, which amounts to
little more than a simple synthesis of its corporate website.
Driven by the evident
success of Apple's service, many other mobile device manufacturers have
pursued similar strategies for getting third-party designed content onto
their handsets. Google's Android Market provides applications for all
handsets using that operating system and is known for being somewhat
less moderated and quality-controlled than Apple's. Nokia's Ovi store
provides downloads for the company's Symbian and Series 40 devices, and
Palm, Blackberry, Microsoft, and others have similar, smaller services.
Many network carriers are also
developing app stores for their own subscribers. A joint effort by at
least 40 such companies — the Wholesale Applications Community (WAC) —
endeavors to provide a similar, yet universal, application download
platform for multiple handset and operating system platforms.
At the time of this
writing, client-side applications are still a growing phenomenon, and
most mobile users with suitable handsets have downloaded at least one to
their device. Where does this all leave a mobile web developer?
Although opinions vary, there is increasingly a consensus that mobile
applications will not end up being the predominant, or certainly not the
only, way of accessing third-party content on a mobile device. While
many developers were drawn to the initial commercial attraction — and
platform homogeneity — of Apple's App Store and iPhone environment, that
enthusiasm has faded with the realization that only the most successful
applications are commercially viable and that applications must be
ported or rewritten for each client-side environment: There is no way to
make an iPhone application run on a non-Apple device. Similarly, the
increasing popularity of Google's mobile operating system has drawn
developers to that platform, and yet the number of diverse device models
that run Android introduces a new set of interoperability challenges.
Against this backdrop
of jaded enthusiasm for investing in client-side applications, the
mobile web yet again starts to become a compelling option for many
developers. A mobile web browser may not (yet!) be the best runtime
environment to host a high-performance application such as an action or
arcade game, but for many other applications the web medium is indeed a
feasible alternative for delivering a good experience to a mobile user.
The mobile web brings
with it a number of particular attractions in this regard. First, the
quality of mobile browsers and the popularity of the WebKit engine on
higher-end devices (notably the same ones as those with app stores)
means that rich, interactive web content is quite feasible. It is
possible to create websites that are almost indistinguishable from a
native application on a given device, and indeed some manufacturers
provide guidelines concerning the HTML and CSS styling required to do
this.
Second, devices are starting
to provide richer APIs for web applications to access their local
functionality and hardware. The BONDI set of standards prescribes how
JavaScript-based scripts can access (with the user's permission) such
local data as the device's file system, gallery, contacts and calendar.
Similarly, there is the potential for web applications to access camera
functionality, geolocation, and some telephony features of the device —
all of which have previously been posited as reasons for choosing to
build native applications. At the time of this writing, newly released
models are starting to support such APIs. "Bridging" technologies, such
as the popular PhoneGap, also allow you to write self-contained HTML-
and JavaScript-based applications that can access native capabilities
and APIs, on multiple platforms, in the meantime.
Third, and perhaps most
critically, the mobile web provides a single, cross-platform medium for
building applications and services that work on all the mobile operating
systems and browsers. As you've seen, fragmentation and device
diversity are a critical challenge, but it remains far easier to craft a
mobile website that works reliably on all mobile devices than it would
be to build or rewrite entirely different applications for every
operating system. The fact remains that whichever platform you might
choose to target first for a client-side application, the majority of
your potential users will be using one of the others. A mobile website,
conversely, can be given a respectable chance of working on every user's
web-enabled handset from the day it is launched — and can be easily and
centrally upgraded as it develops and grows.
As is surely becoming clear by
now, the mobile industry is fast moving, and trends come and go.For most types
of applications, an investment in web-based technology is likely to be
more valuable in the long term than platform-by-platform client-side
development.
2. Mobile Widgets
Straddling the philosophies
of both the native client and the mobile web, widgets are small
applications built with mobile web technologies, and are installed on a
user's device. Mobile widgets
are similar to the widget concept found on desktop operating systems
(where they often appear on the desktop or "dashboard" screens) and
typically provide small, focused pieces of regularly updated
information, such as sports scores, news tickers, or weather updates. Figure 2-19
shows a Nokia N770 Internet tablet running a selection of home screen
widgets, including a news reader, a clock, and a search bar.
As far as developing widgets
is concerned, most web developers will feel familiar with the standards
used for mobile deployments: HTML, CSS, and JavaScript. But, in
contrast to true web-based applications, widget component files are
zipped into a compressed archive (along with a descriptor file) which
can be downloaded and installed by users like an application. Because of
their typically small size and low complexity, the widget approach is
probably not suitable for helping to mobilize a full CMS-driven website.
However, they can serve as useful promotional tools — for example, to
display news from your site on the user's home screen — which when
clicked will launch the user's full mobile browser to visit the site
itself.
3. Messaging and Short Codes
Back in the mid- to
late-1990s, and long before the advent of data network connections,
mobile devices did not do much more than make and receive voice calls.
But one small innovation in the original GSM Specification, which
started off as little more than a mechanism for utilizing spare network
capacity, soon became a global phenomenon: the Short Message Service
(SMS), now known more colloquially as texting.
SMS originally provided
the sending of a short text message (up to 160 characters in length)
from one handset to another on the same mobile network. It served as a
non-intrusive way for people to send small messages to friends, family,
and colleagues. Given that nearly all devices at the time had numeric
keypads, the length limit was not considered a particular restriction
compared to the usability of typing them.
For several years, SMS
remained of limited appeal, until the time when most networks allowed
them to be sent from one network to another. A "viral" networking effect
ensued as more people became familiar with the concept, and texting
quickly became a mass-market medium. At the end of 2009, 4 billion
messages were being sent daily, worldwide.
Since then, SMS has
evolved from being a simple text protocol between individuals. The
Enhanced Messaging Service (EMS) standard allowed users to insert
formatting, animated icons, and simple sounds into their messages. A
technically more complex successor, the Multimedia Messaging Service
(MMS) standard, allows larger, richer messages containing sound, video,
ringtones, and the like.
More importantly for
this discussion, these messaging technologies are often used between
users and automated systems, not just between individuals. Most network
carriers provide gateways that permit external systems to send and
receive SMS messages to and from users on their network, and a number of
companies provide aggregator and wholesale messaging services to make
such integrations easy across multiple network carriers.
From the point of view of
a web developer, this provides a number of interesting possibilities.
As well as delivering web pages to a mobile phone, it's almost as easy
to send an SMS (or even an MMS) to the user (assuming you know his
mobile telephone number). This provides a push mechanism to complement the pull philosophy of a website.
Further, most mobile carriers support short codes,
which are shortened numbers, usually 3 to 5 digits long, that users can
use to send messages to network systems or external gateways. By
registering a short code (or leasing a keyword on an existing one), a website or other system can receive messages from users as well as send them.
Commonly, this configuration
is used to promote mobile web-based services on products or printed
media. For example, a soft drink can might feature a promotion urging
the purchaser to "Text BUBBLE to 5557," and this message is routed to
the confectioner's server registered with the BUBBLE keyword on short
code 5557. In response, that server can send back an MMS or SMS
containing a link to the mobile version of their website, and the user
can click that to open her web browser and see the promotion. (Most
mobile devices detect web addresses in text messages and render them as
links for the user to click. For those that do not, it is also possible
to send special binary "WAP push" messages that invoke the browser
directly.)
Messaging can also become an
integral way in which a web service interacts with its users. For
example, the popular social networking site Twitter has both a website
and a mobile website. But at its launch, the mobile user-interface for
the service was predominantly SMS-based. As well as sending status
updates to the service via a short code, users could send instructions
to follow or unfollow other users via a special SMS syntax.
So although mobile messaging
uses a set of technologies more or less distinct to the Web, it is
important for you to remember that there are plenty of ways in which you
can use SMS or MMS capabilities to augment, or help discover, any
website.
4. Bar Codes
One of the common
frustrations voiced by users of mobile websites is that entering a long
and complex URL into a mobile browser can be arduous, even for those
devices with full keyboards. This is one reason why mobile search and
directory services have been popular. But there is still a need for site
owners to be able to indicate to a user that a mobile website exists
and to be able to help them navigate to it quickly.
You've seen how SMS messages
sent to short codes can generate responses to users containing clickable
links, but a more visual technique exists — in the form of mobile bar
codes. These are mobile-device-readable images that contain encoded
information that the device can act upon. Figure 2-20 shows a typical bar code containing a web address.
Pioneered in Japan in the
last decade, a number of standards originally emerged to encode data in
bar codes and in forms that are easily read by camera-enabled mobile
devices. At the time of this writing, the most prevalent is the QR-code
format shown in Figure 6, and most new devices contain built-in readers for them.
Users simply start their bar
code reader application, point the camera at the bar code itself (be
itin printed media, on a billboard, or on a screen), and the device
recognizes it and decodes the image. In the case of a code containing a
web address, the reader typically opens the device browser and navigates
directly to it, providing a quick and user-friendly way of attracting
visitors to the site. Figure 7 shows such a reader in use.
Although mobile bar codes have
yet to see as much widespread use in the rest of the world as they have
had in Japan, they remain a viable way to encourage users to visit
mobile sites and make it easy for them to do so.
5. Geolocation and Augmented Reality
It's exciting to remember that a
mobile device is not the same as a desktop computer. While that may
seem obvious, it is important to remember the enhancements that a mobile device has over its larger cousin, rather than just the more evident limitations.
In other words, you should constantly explore the characteristics of a
mobile device that make it unique, not only in terms of its technology,
but also the way in which it is used.
The word mobile
is an adjective, and the fact that these devices can be held and used
anywhere — the home, the office, the car, the street, the countryside —
is itself a unique characteristic. More than that, the device itself,
often in conjunction with the mobile network, can provide feedback as to
exactly what that location is, at any time. Suddenly, every mobile user
potentially owns a modern-day compass, sextant, and detailed world map
in their hand.
For many years, the main way
of locating a mobile device was a cellular-based process: by
triangulating the relative positions of cell towers, a mobile carrier
could determine a reasonable position for the device. But this
information resided within the network and was not necessarily easy for
third parties (such as mobile web developers) to access, notwithstanding
the privacy concerns of doing so without user agreement.
In late 2006, however, mobile
devices containing Global Positioning System (GPS) capabilities started
to increase in number and became popular in the mid- to high-end market.
Such devices use satellite positioning to determine their longitude,
latitude, and altitude — without assistance from the cellular network —
and expose this data to applications that run on the device.
Early to capitalize on this new
capability, companies like Google started to provide mapping
applications for mobile devices, where of course the most impressive
feature was for the device to identify the user's location and plot it
on the map. Additionally, by correlating those locations with the cells
that the devices were using for their data connections, such services
built up databases of cell tower locations, thereby providing
approximate location services to those handsets still without GPS.
(Similar databases that correlate WiFi access points to location further
enhance this concept). More recently, most high-end devices now also
include compass and accelerometer hardware, allowing applications to
determine the device's direction and orientation as well as location.
Figures 8 and 9
show the Nokia Maps application running on a Symbian S60 device, which
uses GPS positioning and provides satellite images, vector maps, and
driving and walking directions between points.
As well as the
capability for native client apps to access such geolocation data,
mobile browsers themselves are increasingly able to do so via JavaScript
APIs defined by the W3C. For websites and services that have
location-based capabilities or relevance, this opens up lots of
opportunities: Imagine a mobile user who doesn't have to type his
location to find the nearest store on a retailer's website, for example.
As a result of
this commoditization of the geolocation data itself, there has been a
renaissance in services that are built upon it. Naturally, mapping and
navigation applications are popular, but there has also been a rise in
location-based social networks, such as Foursquare and Gowalla.
One of the most visually appealing applications of location data is known as augmented reality
(AR), whereby a mobile device that has been geolocated is used to view
information about the local area. By combining geolocation with data
from a device's compass and accelerometer, a view (through the camera)
of the user's surroundings can be overlaid with information and data. Figure 10 shows Wikitude, an augmented reality browser that overlays Wikipedia information onto the camera image.
At the time of this
writing, such services are fairly new and still rapidly evolving.
Suffice it to say, mobile devices provide a unique way to blend
location, web-based data, and mobility, and it is highly likely that
such technologies will evolve rapidly over the coming decade.
